Method, system and computer program product for millicode store access checking instructions

ABSTRACT

A system, method and computer program product for a millicode store access checking instruction are provided. The system includes an operand access control register (OACR) including a test modifier indicator. The system also includes an instruction unit subsystem for fetching and decoding instructions. The instructions include a millicode instruction with an operand defining an address to check for a store access exception. The system further includes an execution unit to execute the millicode instruction. The execution unit performs a method. The method includes receiving the millicode instruction from the instruction unit subsystem, testing for the store access exception at the address as if the test modifier is set absent an update to the OACR, and outputting a result of the testing for the store access exception.

BACKGROUND OF THE INVENTION

This invention relates generally to improvements in computer processorsthat execute relatively simple instructions in hardware controlledexecution units and execute relatively complex instructions in amilli-mode architected state with vertical microcode (i.e., millicode)routines executing in the same hardware controlled execution units, andmore particularly to millicode store access checking instructions withreduced delays.

Instruction sets used in computer systems employing so-called ComplexInstruction Set Computing (CISC) architecture include both simpleinstructions (e.g., Load, or Add) and complex instructions (e.g.,Program Call, or Load Address Space Parameters). As the computer systemshave become more powerful, larger percentages of the instruction sethave been implemented using hardware execution units to increase thesystems performance. Conventionally, complex functions are implementedin microcode because building hardware execution units to execute themis expensive and error prone.

Implementing complex functions in microcode provides flexibility to fixproblems and expandability in that additional functions can be includedlater. In certain prior art machines, where much of the processor ishardware controlled, a dedicated microprocessor based execution unit isoften provided in order to implement the complex functions. This unitcan be microprogrammed to execute complex instructions and complexfunctions such as handling interrupt conditions.

A milli-mode operation enables implementation of complex functions in alarge, hardware controlled, pipelined, general-purpose digital computerwithout an additional dedicated microprocessor-based execution unit.Milli-mode implements these complex functions with flexibility providedby firmware and avoids a packaging problem introduced by the inclusionof the additional microprocessor hardware. Rather than an additionalmicroprocessor, milli-mode uses preexisting dataflow and hardwarecontrolled execution units of a pipelined processor to accomplishcomplex functions. Additional hardware controlled instructions (privatemilli-mode only instructions) are added to provide control functions orto improve performance. These private milli-mode instructions augmentthe architected instruction set. Milli-mode routines can intermingle themilli-mode only instructions with architected instructions to implementcomplex functions.

Milli-mode detection logic in instruction decode logic detects a need toenter milli-mode, and this causes millicode routines to be fetched. Themillicode routines are decoded by the decoder hardware and dispatchedfor execution in the same way as the architected macro-instructions(system-mode instructions).

A majority of the architected macro-instructions that are implemented ashardware controlled instructions can be executed in milli-mode. The setof instructions available in milli-mode can be considered to be analternate architecture that the processor can execute.

The hardware-executed instructions which are valid only for millicodeare generally of a format and a function similar to those of thearchitected instructions. In this way, the unique hardware required toimplement these instructions is minimized, and the simplicity of thehardware design is maintained. This simplicity of hardware controls is achief advantage of millicode over other forms of internal code (e.g.,microcode), which require considerably more unique hardware.

A disadvantage of a millicoded design is that some complex operationsrequire more internal code instructions and/or more machine cycles thanwith some forms of microcode. In some cases, this is due to theinefficiency of the base instruction set when used to perform thesecomplex operations. Depending on the frequency with which theseoperations are performed, the impact on overall system performance maybe significant.

Millicode that accesses storage, just like architected instructions, areexecuted by generic hardware constructs. Therefore, millicode is subjectto various kinds of hardwired architectural access exception checks anddefault cache operation behavior. It is desirable for millicode to becapable of accessing a storage location, as well as to avoid or altercertain default operand cache behavior. Any storage access may requireproper authority. Prior approaches provide an operand access controlregister (OACR) mechanism to override many aspects of default operandcache access characteristics. One such approach includes suppressinginterrupts when an access exception is detected. However, this issubject to pipeline delays when the OACR needs to be written (afterexecution) before the affected instruction can issue its operand fetch(occurring much earlier in the processor pipeline). This results in a“bubble” in the pipeline that translates to a reduction in instructionsper cycle as delays are incurred to rectify interlock condition betweenthe instruction and the OACR. One example is described in U.S. Pat.5,790,844, which provides a “load and access test” that can check for“load” type exceptions without taking an actual interrupt, but requiresa test “tag” from the OACR to be updated to check for a “store” typeaccess exception.

It would be beneficial to develop milli-mode assist instructionsenabling millicode access to a storage operand and directly checking forstore-type access exceptions without incurring OACR update interlockdelays. Accordingly, there is a need in the art for millicode storeaccess checking instructions.

BRIEF SUMMARY OF THE INVENTION

An exemplary embodiment includes a system for a millicode store accesschecking instruction. The system includes an operand access controlregister (OACR) including a test modifier indicator. The system alsoincludes an instruction unit subsystem for fetching and decodinginstructions. The instructions include a millicode instruction with anoperand defining an address to check for a store access exception. Thesystem further includes an execution unit to execute the millicodeinstruction. The execution unit performs a method. The method includesreceiving the millicode instruction from the instruction unit subsystem,testing for the store access exception at the address as if the testmodifier is set absent an update to the OACR, and outputting a result ofthe testing for the store access exception.

Another exemplary embodiment includes a method for a millicode storeaccess checking instruction in a processor. The method includes fetchinga millicode instruction with an operand defining an address to check fora store access exception. The method also includes testing for the storeaccess exception at the address as if a test modifier in an OACR is setabsent an update to the OACR. The method further includes outputting aresult of the testing for the store access exception.

A further exemplary embodiment includes computer program product forexecuting a millicode store access checking instruction. The computerprogram product includes a computer-readable storage medium storinginstructions for executing the millicode store access checkinginstruction. The millicode store access checking instruction includes amethod of accessing an operand defining an address to check for a storeaccess exception, and testing for the store access exception at theaddress as if a test modifier in an OACR is set absent an update to theOACR. The method further includes outputting a result of the testing forthe store access exception.

BRIEF DESCRIPTION OF THE DRAWINGS

Referring now to the drawings wherein like elements are numbered alikein the several FIGURES:

FIG. 1 depicts a block diagram of a system for millicode store accesschecking instructions in accordance with an exemplary embodiment;

FIG. 2 depicts an instruction format for a test access character withtest modifier instruction in accordance with an exemplary embodiment;

FIG. 3 depicts an instruction format for a store character with testmodifier instruction; and

FIG. 4 depicts a process for implementing millicode store accesschecking instructions in accordance with an exemplary embodiment.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

An exemplary embodiment of the present invention provides millicodestore access checking instructions. Access checking is performed todetect error conditions associated with attempts to access storage, suchas a lack of valid access authority to a protected location, an invalidaddress, and the like, that can result in an exception. The millicodestore access checking instructions enable access to a storage operandand directly check for store-type access exceptions without incurringoperand access control register (OACR) update interlock delays in apipelined processing system. The OACR can provide information regardinghow to interpret an address presented by a millicode routine. Forexample, the OACR may include a storage access key, an address-spacecontrol, an addressing mode, and an addressing type (e.g., real,virtual, host real, absolute, or hardware system area), in addition tospecial controls which can block program event recording (PER) storagealteration detection or protection exceptions, and can pretest forstore-type access exceptions. However, accessing the OACR duringpipelined operation can incur a delay penalty, as an update to the OACRmay be needed prior to completing execution of an instruction that canresult in an exception. Rather than using the OACR to block exceptionsor simply blocking interrupts, millicode assist instructions aredesigned to check for an exception and set a condition code in responseto the check. In an exemplary embodiment, the millicode assistinstructions that are provided include: test access character with testmodifier (TACTM) and store character with test modifier (STCTM). TheTACTM checks for both fetch-type and store-type exceptions whileaccessing storage. If an access exception is detected, a condition codeis updated but no interrupt is taken. The STCTM checks for store-typeexceptions, but does not attempt to update storage. If an accessexception is detected, an interrupt is taken; otherwise, it acts like ano operation (no-op) instruction. Further details regarding the TACTMand STCTM are provided herein.

Referring now to FIG. 1, elements of a system 10 relevant to thisinvention include a system storage 11, and a cache memory unit 12. Thesystem 10 may be a processor capable of executing instructions using apipeline. The system storage 11 contains the instructions that theprocessor is executing as well as data that the instructions aremanipulating. The cache memory unit 12 may include a copy of the dataand instructions the processor is presently executing, includingmilli-mode routines.

An instruction unit subsystem 16 includes an instruction buffer (notshown in FIG. 1), instruction registers 18 and an instruction decoder20. The instruction unit subsystem 16 receives macro-instructions,millicode instructions, and data from the cache memory unit 12.Instructions are parsed and placed into the instruction registers 18.The instruction decoder 20 reads the contents of the instructionregisters 18, decodes the instruction (or causes an operationexception), and passes the instruction to an instruction queue forsequential execution by a hardware execution unit 24. Each hardwareexecution unit 24 has access to a set of general purpose registers andaccess registers (normal-GRs/ARs) 21 for normal macro-code instructionexecution and to a set of general purpose registers and access registers(milli-GRs/ARs) 23 for millicode instruction execution. Control logiccontrols the exchange of data between the two sets of registers whenbeginning or terminating a millicode routine. The instruction unitsubsystem 16 also includes an operand fetch unit 27 with one or moreOACRs 28. The operand fetch unit 27 can fetch operands for instructionsfrom the cache memory unit 12 and may also fetch operands from thesystem storage 11. The OACR 28 can provide operand access informationduring a millicode routine as well as block PER storage alterationdetection or protection exceptions, and can pretest for store-typeaccess exceptions. The OACR 28 may be updated by the execution unit 24.

Milli-mode detection logic 26 is coupled to the instruction registers 18and detects when a macro-instruction, which is being decoded, is of atype that is to be interpreted in a milli-mode operation. When thisoccurs, the milli-mode detection logic 26 generates an entry pointaddress and passes this address along to instruction fetch control logic25 and places the instruction decoder 20 into a milli-mode operatingstate. In this state the instruction decoder 20 is enabled to decodemilli-mode instructions, and operand fetch 27 will start processingoperand access according to OACRs 28 when instructed. Milli-modeinstructions are vertical microcode, consisting of a mixture of regularmicrocode instructions and special milli-mode only instructions, all ofwhich can be executed in the execution unit 24. The special instructionsprovide control functions needed by the millicode routines. The set ofmillicode routines reside outside of the program addressable storage.

The system effects of an executed instruction are architecturallyvisible in the completion logic 30. Signal lines between the completionlogic 30 and the instruction decoder 20 allow the instruction decoder 20to keep track of instruction completion. A program status word (PSW) inPSW register 31 controls execution of the macro-program. Similarly, thesystem 10 also includes a milli-PSW register 33, which controlsexecution of the milli-routine. Both the execution unit 24 and thecompletion logic 30 are connected to read from/write to the PSW and themilli-PSW registers 31 and 33. Thus, at any given point the executionunits 24 or the completion logic 30 can read or update the appropriateone of the PSW register 31 and/or milli-PSW register 33. The PSWregister 31 includes a condition code (CC) that the execution unit 24can update while executing an instruction. The milli-PSW register 33also includes a CC. The completion logic 30 updates the CC in either thePSW register 31 or milli-PSW register 33 upon completing an instruction.The CC in the PSW register 31 is modified based on a macro-codeinstruction, while the CC in the milli-PSW register 33 is modified basedon a millicode instruction although milli-mode instructions cansometimes directly update the PSW register 31 including its CC.

A processor state unit 40 maintains the entire updated status of thesystem 10 both in regular mode and milli-mode operation. In the event ofa detected error, the processor state unit 40 provides a resource torecreate the status of the system 10 from a check point state in orderto allow a retry of the error causing operation.

Milli-mode is enabled when the milli-mode detection logic 26 recognizesthat the macro-instruction being decoded is to be implemented withmillicode. In response to this recognition, the milli-mode detectionlogic 26 signals the instruction decoder 20, the instruction fetchcontrol logic 25 and register controls in the execution unit 24. Inresponse to the milli-mode recognition signal from the milli-modedetection logic 26, the instruction decoder 20 suspends macro-modedecoding, the execution unit register control optionally copies thecontents of some of the normal-GRs/ARs 21 to the milli-GRs/ARs 23 andcauses the system 10 to subsequently use the milli-GRs/ARs 23. Themilli-mode detection logic 26 generates a millicode entry point address.

The entry point address (generated by the milli-mode detection logic 26)is used by the instruction fetch control logic 25 to address the cachememory unit 12. Milli-instructions are sent to the instruction registers18 where the instruction decoder 20 decodes them and schedules them forexecution.

When the system 10 enters milli-mode, it executes and completes themacro-instructions already pipelined conceptually prior to theinstruction that caused entry into milli-mode. As the system 10completes the macro-instructions, it updates the appropriatemilli-GRs/ARs 23. At the same time, the system 10 decodes and executesthe milli-instructions that implement the macro-instruction that causedentry into milli-mode.

At some point the macro-instruction immediately prior to the instructionthat caused entry to milli-mode will be indicated completed in thecompletion logic 30. Only then does the system 10 begin to complete themilli-instructions. The system 10 then continues decoding, executing andcompleting the milli-instructions.

Eventually, the milli-mode detection logic 26 recognizes a millicode END(MEND) milli-instruction. When the milli-mode detection logic 26 detectsa MEND milli-instruction, it causes the system 10 to cease fetchingmilli-instructions. Further, when MEND is detected, the milli-modedetection logic 26 puts the instruction decoder 20 in macro-mode andcauses the system 10 to begin fetching macro-instructions. Millicodeexplicitly updates all registers, so there is no transfer of registercontent when going from milli-mode operation to regular operation.Completion of a MEND milli-instruction causes the completion logic 30 tobegin completing macro-instructions.

The system 10 can also enter milli-mode in response to an interrupt.When the completion logic 30 detects an interrupt, the interruptpriority logic 45 determines that an interrupt is to be serviced and itsignals the instruction fetch control logic 25, causing the instructiondecoder 20 to initiate milli-mode. The recognition of an interruptioncondition causes the system 10 to halt macro-mode execution at the nextinterruptible point. The interrupt priority logic 45 also generatescontrol inputs which are used by the milli-mode detection logic 26 togenerate an entry point address with which to address the memory cacheunit 12. These milli-instructions are sent to the instruction registers18 where the instruction decoder 20 decodes them and schedules them forexecution at the appropriate hardware execution elements.

The system 10 proceeds to decode, execute and complete themilli-instruction in the milli-routine for interrupts. Eventually, theinstruction decoder 20 recognizes a MEND milli-instruction. This causesthe instruction decoder 20 to stop decoding in milli-mode. Depending onwhether or not there are additional interrupts that require servicing,the decoder hardware will either redo the interrupt process or return todecoding macro-instructions from the cache memory unit 12.

Millicode statements, just like hardware executed macrocodeinstructions, are subject to access exception tests. That is, ifmillicode accesses a storage operand and an exception occurs, theinterrupt logic 45 can interrupt the millicode routine and pass controlto a program exception interrupt handler.

In many cases, millicode must explicitly detect access exceptions forstorage operands while at the same time retaining control in the currentmillicode routine to ensure that exceptions are handled correctly andwith the right priority. The system 10 has a Test Access Character WithTest Modifier (TACTM) millicode instruction as illustrated in FIG. 2 tomeet this requirement with the addition of minimal unique hardware.Similarly, millicode must explicitly detect access exceptions forstorage operands, such that it expects to be interrupted if an exceptionis detected, but does not intend to do any actual storage update even ifthe access is allowed. The system 10 has a Store Character with TestModifier (STCTM) millicode instruction as illustrated in FIG. 3 to meetthis requirement with the addition of minimal unique hardware.

FIG. 2 depicts one embodiment of an instruction format for a TACTM 200millicode instruction. The TACTM 200 includes a milli-opcode 202 toidentify the instruction, as well as two potential operands, B 204 and D206. The operands B 204 and D 206 supply address information for theTACTM 200. In an exemplary embodiment, the operand B 204 is a storagebase address value. B 204 may be defined in the milli-GRs/ARs 23. Theoperand D 206 is a storage displacement value that can be offsetrelative to the value of B 204. The TACTM 200 tests for accessexceptions in a byte of the system storage 11 of FIG.1 as addressed bythe combination of B 204 and D 206. In executing the TACTM 200, accessexceptions associated with the storage access are blocked, and do notresult in a program interruption via the interrupt logic 45. Instead, avalue is set in the CC of the milli-PSW register 33. No registers areloaded with the storage data. A test modifier in the OACR 28 indicatesthat a special test state is active. PER can assist in debuggingprograms by permitting the program to be alerted to various types ofevents, such as execution of a successful branch instruction, fetchingof an instruction from a designated storage area, alteration of thecontents of the designated storage area, and the like. Blocking the PERstorage alteration indicator may be desired while executing millicodeinstructions that would otherwise trigger an exception. The TACTM 200checks for store access exceptions (right to modify) as well as forfetch access exceptions (right to use) as if the test modifier in theOACR 28 was set and executes as if the block PER storage alterationindicator in the OACR 28 is also set. Therefore, pipelined instructionflow can proceed without the delay that would otherwise occur in waitingfor an explicit update to the OACR 28. The actual values of the testmodifier and the block PER storage alteration indicator in the OACR 28are unchanged by the TACTM 200 instruction. The TACTM 200 provides ameans to check for access exceptions without having to set theassociated OACR 28 test modifier. This provides an improvement overprior art systems, which may have to update the OACR 28, resulting in anaddress generation interlock (AGI) delay before testing for the accessexception. The AGI delay, which is a byproduct of instruction accessdependencies between an instruction and accessing the OACR 28, can beavoided.

The TACTM 200 checks for both fetch-type and store-type exceptions whileaccessing the system storage 11. If an access exception is detected, theCC is updated in the milli-PSW register 33, but no interrupt is taken.The CC in the milli-PSW register 33 is set to indicate whether anyaccess exception conditions were present for the operand storage accessas depicted in table 1.

TABLE 1 Millicode Condition Code Values for TACTM Code Condition 0 Noaccess exceptions found 1 Access exception found and blocked 2 Reserved3 Host translation found and blocked

The access exceptions do not cause an interrupt, but instead set the CCin the milli-PSW register 33 as shown in Table 1. In particular, theTACTM 200 sets the CC to 0 if no access exception is detected, and setsit to either 1 or 3 if the instruction detects an access exception. Theinstruction sets the CC to 3 when the current program is executing inemulation and the access exception is associated with addresstranslation using the host setup. The instruction sets the CC to 1 forall other access exceptions. Hardware suppresses reporting of theseaccess exceptions to any other architected states and uses the accessexception information only to set the CC. The additional hardwareintroduces no timing or performance constraints since access exceptioninformation is available with the same timing as the data beingretrieved.

FIG. 3 depicts one embodiment of an instruction format for a STCTM 300millicode instruction. The STCTM 300 includes a milli-opcode 302 toidentify the instruction, as well as two potential operands, B 304 and D306. Even though the STCTM 300 appears similar in form to a storecharacter instruction, no storage update is actually performed. Theoperands B 304 and D 306 supply address information for the STCTM 300 tocheck for a store-type exception in the system storage 11 of FIG. 1. Inan exemplary embodiment, the operand B 304 is a storage base addressvalue. B 304 may be defined in the milli-GRs/ARs 23. The operand D 306is a storage displacement value that can be offset relative to the valueof B 304. The STCTM 300 does not alter the value at the address definedby the operands B 304 and D 306. Similar to the TACTM 200 of FIG. 2, theSTCTM 300 executes as if the test modifier and the block PER storagealteration indicator in the OACR 28 of FIG. 1 are set. The actual valuesof the test modifier and the block PER storage alteration indicator inthe OACR 28 are unchanged by the STCTM 300. The STCTM 300 provides ameans to check for access exceptions without having to set theassociated OACR 28 test modifier. This provides an improvement overprior art systems, which may have to update the OACR 28, resulting in anAGI delay before testing for the access exception. The STCTM 300 checksfor only store-type exceptions, but does not attempt to update thesystem storage 11 of FIG. 1. If an access exception is detected, aninterrupt is taken via the interrupt logic 45; otherwise, the STCTM 300acts like a no-op instruction. It will be understood that although themill-opcodes 202 and 302, as well as B 204 and 304, and D 206 and 306are depicted in FIGS. 2 and 3 at specific bit positions in theinstructions, different lengths or bit positions are included within thescope of the invention.

Turning now to FIG. 4, a process 400 for implementing millicode storeaccess checking instructions will now be described in reference to FIGS.1-3 and in accordance with an exemplary embodiment. At block 402, theinstruction unit subsystem 16 fetches a millicode instruction with anoperand defining an address to check for a store access exception. Theoperand may include a storage base address value and/or a storagedisplacement value addressing the system storage 11, such as B 204 and304 and/or D 206 and 306. The system 10 executes the millicodeinstruction in milli-mode.

At block 404, the execution unit 24 tests for the store access exceptionat the address as if the test modifier in the OACR 28 is set absent anupdate to the OACR 28. This makes the millicode instruction appear as ifa test instruction is being executed regardless of the actual state ofthe OACR 28. Furthermore, the testing for the store access exception atthe address can also be performed as if the block PER storage alterationindicator in the OACR 28 is set absent an update to the OACR 28. Thus,delays due to AGI are prevented as an additional write to set the testmodifier and/or block PER storage alteration indicator in the OACR 28 isavoided. In an exemplary embodiment, both the TACTM 200 and the STCTM300 perform testing for the store access exception. The TACTM 200 alsotests for a fetch access exception at the address as if the testmodifier is set absent an update to the OACR 28. The TACTM 200 mayperform testing for the fetch access exception as if the block PERstorage alteration indicator is set absent an update to the OACR 28.Again, delays due to AGI between the millicode instruction and updatingthe OACR 28 are prevented as an additional write to set the testmodifier and/or block PER storage alteration indicator in the OACR 28 isavoided.

At block 406, the execution unit 24 outputs a result of the testing forthe store access exception. The execution unit 24 can update theprocessor state unit 40 and provide the result to the completion unit 30for further operations. When the millicode instruction is the TACTM 200,the completion unit 30 updates the CC in the milli-PSW register 33 aspreviously described. Additionally, the completion unit 30 may updatethe CC in the milli-PSW register 33 for the TACTM 200 in response thetesting for the fetch access exception. When the millicode instructionis the STCTM 300, the completion unit 30 passes information to theinterrupt logic 45 that generates an interrupt in response to detectingthe store access exception. Additionally, the execution unit 24 willperform no storage update.

It will be understood that the process 400 can be applied to anyprocessing circuitry that incorporates a processor pipeline. Forexample, process 400 can be applied to various digital designs, such asa microprocessor, an application specific integrated circuit (ASIC), aprogrammable logic device (PLD), or other such digital devices capableof processing instructions. Therefore, the system 100 of FIG. 1 canrepresent a variety of digital designs that incorporate processingcircuitry.

Technical effects and benefits include increasing instruction processingefficiency through avoiding updates to an OACR when checking for accessexceptions. The TACTM and STCTM can execute as if test modifier andblock PER storage alteration indicators in the OACR are set. This allowsthe TACTM instruction to check for store access exceptions as well asfor fetch access exceptions without an AGI delay. An AGI delay istypically associated with an instruction that has advanced further in aprocessing pipeline that is dependant upon an instruction or operandthat is further upstream in the processing pipeline. This also allowsthe STCTM instruction to check for store access exceptions and take aninterrupt if an access exception is detected.

As described above, the embodiments of the invention may be embodied inthe form of computer-implemented processes and apparatuses forpracticing those processes. Embodiments of the invention may also beembodied in the form of computer program code containing instructionsembodied in tangible media, such as read-only memory (ROM), electricallyerasable programmable read-only memory (EEPROM), flash memory, or anyother computer-readable storage medium, wherein, when the computerprogram code is loaded and executed in a computer, the computer becomesan apparatus for practicing the invention. The computer program code maybe firmware, or code embedded within an integrated circuit (IC) chip,such as a processor. The present invention can also be embodied in theform of computer program code, for example, whether stored in a storagemedium, loaded into and/or executed by a computer, or transmitted oversome transmission medium, such as over electrical wiring or cabling,through fiber optics, or via electromagnetic radiation, wherein, whenthe computer program code is loaded into and executed by a computer, thecomputer becomes an apparatus for practicing the invention. Whenimplemented in a microprocessor, the computer program code segmentsconfigure the microprocessor to create specific logic circuits.

While the invention has been described with reference to exemplaryembodiments, it will be understood by those skilled in the art thatvarious changes may be made and equivalents may be substituted forelements thereof without departing from the scope of the invention. Inaddition, many modifications may be made to adapt a particular situationor material to the teachings of the invention without departing from theessential scope thereof. Therefore, it is intended that the inventionnot be limited to the particular embodiment disclosed as the best modecontemplated for carrying out this invention, but that the inventionwill include all embodiments falling within the scope of the appendedclaims. Moreover, the use of the terms first, second, etc. do not denoteany order or importance, but rather the terms first, second, etc. areused to distinguish one element from another.

1. A system for a millicode store access checking instruction, thesystem comprising: an operand access control register (OACR) including atest modifier indicator; an instruction unit subsystem for fetching anddecoding instructions, wherein the instructions include a millicodeinstruction with an operand defining an address to check for a storeaccess exception; and an execution unit to execute the millicodeinstruction, the execution unit performing a method comprising:receiving the millicode instruction from the instruction unit subsystem;testing for the store access exception at the address as if the testmodifier is set absent an update to the OACR; and outputting a result ofthe testing for the store access exception.
 2. The system of claim 1wherein the millicode instruction further comprises a second operand tocombine with the operand defining the address to check for the storeaccess exception, and further wherein the operand is a storage baseaddress value and the second operand is a storage displacement value. 3.The system of claim 1 wherein the OACR further comprises a block programevent recording (PER) storage alteration indicator and the testing forthe store access exception is performed as if the block PER storagealteration indicator is set absent an update to the OACR.
 4. The systemof claim 1 wherein the result of the testing for the store accessexception is output to interrupt logic that generates an interrupt inresponse to detecting the store access exception.
 5. The system of claim1 wherein the result of the testing for the store access exception isoutput to a condition code.
 6. The system of claim 1 wherein theexecution unit further performs: testing for a fetch access exception atthe address as if the test modifier is set absent an update to the OACR;and outputting a result of the testing for the fetch access exception toa condition code.
 7. The system of claim 6 wherein the OACR furthercomprises a block program event recording (PER) storage alterationindicator and the testing for the fetch access exception is performed asif the block PER storage alteration indicator is set absent an update tothe OACR.
 8. A method for a millicode store access checking instructionin a processor, the method comprising: fetching a millicode instructionwith an operand defining an address to check for a store accessexception; testing for the store access exception at the address as if atest modifier in an operand access control register (OACR) is set absentan update to the OACR; and outputting a result of the testing for thestore access exception.
 9. The method of claim 8 wherein the millicodeinstruction further comprises a second operand to combine with theoperand defining the address to check for the store access exception,and further wherein the operand is a storage base address value and thesecond operand is a storage displacement value.
 10. The method of claim8 wherein the OACR further comprises a block program event recording(PER) storage alteration indicator and the testing for the store accessexception is performed as if the block PER storage alteration indicatoris set absent an update to the OACR.
 11. The method of claim 8 whereinthe result of the testing for the store access exception is output tointerrupt logic that generates an interrupt in response to detecting thestore access exception.
 12. The method of claim 8 wherein the result ofthe testing for the store access exception is output to a conditioncode.
 13. The method of claim 8 further comprising: testing for a fetchaccess exception at the address as if the test modifier is set absent anupdate to the OACR; and outputting a result of the testing for the fetchaccess exception to a condition code.
 14. The method of claim 13 whereinthe OACR further comprises a block program event recording (PER) storagealteration indicator and the testing for the fetch access exception isperformed as if the block PER storage alteration indicator is set absentan update to the OACR.
 15. A computer program product for executing amillicode store access checking instruction, the computer programproduct comprising: a computer-readable storage medium storinginstructions for executing the millicode store access checkinginstruction, the millicode store access checking instruction comprisinga method of: accessing an operand defining an address to check for astore access exception; testing for the store access exception at theaddress as if a test modifier in an operand access control register(OACR) is set absent an update to the OACR; and outputting a result ofthe testing for the store access exception.
 16. The computer programproduct of claim 15 wherein the millicode instruction further comprisesa second operand to combine with the operand defining the address tocheck for the store access exception, and further wherein the operand isa storage base address value and the second operand is a storagedisplacement value.
 17. The computer program product of claim 15 whereinthe OACR further comprises a block program event recording (PER) storagealteration indicator and the testing for the store access exception isperformed as if the block PER storage alteration indicator is set absentan update to the OACR.
 18. The computer program product of claim 15wherein the result of the testing for the store access exception isoutput to interrupt logic that generates an interrupt in response todetecting the store access exception.
 19. The computer program productof claim 15 wherein the result of the testing for the store accessexception is output to a condition code.
 20. The computer programproduct of claim 15 further comprising: testing for a fetch accessexception at the address as if the test modifier is set absent an updateto the OACR; and outputting a result of the testing for the fetch accessexception to a condition code.